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(57) Abstract: A processor such as a parallel hardware-based multithreaded processor (12) is described. The processor can execute 
a computer instruction that is a branch instruction that causes an execution stream to branch to an instruction at an address specified 
in the instruction if a state of a specified state name of the processor is a specified value. 
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BRANCH INSTRUCTIONS IN A MULTITHREADED PARALLEL PROCESSING SYSTEM 

BACKGROUND 
This invention relates to branch instructions. 
5 Parallel processing is an efficient form of information processing of 

concurrent events in a computing process. Parallel processing demands concurrent 
execution of many programs in a computer. Sequential processing or serial processing 
has all tasks performed sequentially at a single station whereas, pipelined processing has 
tasks performed at specialized stations. Computer code whether executed in parallel 
10 processing, pipelined or sequential processing machines involves branches in which an 
instruction stream may execute in a sequence and branch from the sequence to a different 
sequence of instructions. 

BRIEF DESCRIPTION OF THE DRAWINGS 
15 FIG. 1 is a block diagram of a communication system employing a 

processor. 

FIG. 2 is a detailed block diagram of the processor. 

FIG. 3 is a block diagram of a microengine used in the processor of FIGS. 

1 and 2. 

20 FIG. 4 is a diagram of a pipeline in the microengine. 

FIG. 5 shows exemplary formats for branch instructions. 
FIG. 6 is a block diagram of general purpose registers. 

DESCRIPTION 

25 Referring to FIG. 1, a communication system 10 includes a processor 12. 

In one embodiment, the processor is a hardware-based multithreaded processor 12. The 
processor 12 is coupled to a bus such as a PCI bus 14, a memory system 16 and a second 
bus 18. The system 10 is especially useful for tasks that can be broken into parallel sub- 
tasks or functions. Specifically hardware-based multithreaded processor 12 is useful for 

30 tasks that are bandwidth oriented rather than latency oriented. The hardware-based 
multithreaded processor 12 has multiple microengines 22 each with multiple hardware 
controlled threads that can be simultaneously active and independently work on a task. 



1 



WO 01/16715 



PCMJS00/23983 



The hardware-based multithreaded processor 12 also includes a central 
controller 20 that assists in loading microcode control for other resources of the 
hardware-based multithreaded processor 12 and performs other general purpose computer 
type functions such as handling protocols, exceptions, extra support for packet processing 
5 where the microengines pass the packets off for more detailed processing such as in 
boundary conditions. In one embodiment, the processor 20 is a Strong Arm® (Arm is a 
trademark of ARM Limited, United Kingdom) based architecture. The general purpose 
microprocessor 20 has an operating system. Through the operating system the processor 
20 can call functions to operate on microengines 22a-22f. The processor 20 can use any 
10 supported operating system preferably a real time operating system. For the core 
processor implemented as a Strong Arm architecture, operating systems such as, 
MicrosoftNT® real-time, VXWorks and DCUS, a freeware operating system available 
over the Internet, can be used. 

The hardware-based multithreaded processor 12 also includes a plurality 
15 of function microengines 22a-22f. Functional microengines (microengines) 22a-22f each 
maintain a plurality of program counters in hardware and states associated with the 
program counters. Effectively, a corresponding plurality of sets of threads can be 
simultaneously active on each of the microengines 22a-22f while only one is actually 
operating at any one time. 
20 Microengines 22a-22f each have capabilities for processing four hardware 

threads. The microengines 22a-22f operate with shared resources including memory 
system 16 and bus interfaces 24 and 28. The memory system 16 includes a Synchronous 
Dynamic Random Access Memory (SDRAM) controller 26a and a Static Random Access 
Memory (SRAM) controller 26b. SDRAM memory 16a and SDRAM controller 26a are 
25 typically used for processing large volumes of data, e.g., processing of network payloads 
from network packets. The SRAM controller 26b and SRAM memory 16b are used in, 
e.g., networking packet processing, postscript processor, or as a processor for a storage 
subsystem, i.e., RAID disk storage, or for low latency, fast access tasks, e.g., accessing 
look-up tables, memory for the core processor 20, and so forth. 
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The processor 12 includes a bus interface 28 that couples the processor to 
the second bus 18. Bus interface 28 in one embodiment couples the processor 12 to the 
so-called FBUS 18 (FIFO bus). The processor 12 includes a second interface e.g., a PCI 
bus interface 24 that couples other system components that reside on the PCI 14 bus to 
5 the processor 12. The PCI bus interface 24, provides a high speed data path 24a to the 
SDRAM memory 16a. Through that path data can be moved quickly from the SDRAM 
16a through the PCI bus 14, via direct memory access (DMA) transfers. 

Each of the functional units are coupled to one or more internal buses. 
The internal buses are dual, 32 bit buses (i.e., one bus for read and one for write). The 
10 hardware-based multithreaded processor 12 also is constructed such that the sum of the 
bandwidths of the internal buses in the processor 12 exceed the bandwidth of external 
buses coupled to the processor 12. The processor 12 includes an internal core processor 
bus 32, e.g., an ASB bus (Advanced System Bus) that couples the processor core 20 to 
the memory controller 26a, 26c and to an ASB translator 30 described below. The ASB 
15 bus is a subset of the so called AMBA bus that is used with the Strong Arm processor 
core. The processor 12 also includes a private bus 34 that couples the microengine units 
to SRAM controller 26b, ASB translator 30 and FBUS interface 28. A memory bus 38 
couples the memory controller 26a, 26b to the bus interfaces 24 and 28 and memory 
system 16 including flashrom 16c used for boot operations and so forth. 
20 Referring to FIG. 2, each of the microengines 22a-22f includes an arbiter 

that examines flags to determine the available threads to be operated upon. Any thread 
from any of the microengines 22a-22f can access the SDRAM controller 26a, SDRAM 
controller 26b or FBUS interface 28. The memory controllers 26a and 26b each include a 
plurality of queues to store outstanding memory reference requests. The FBUS interface 
25 28 supports Transmit and Receive flags for each port that a MAC device supports, along 
with an Interrupt flag indicating when service is warranted. The FBUS interface 28 also 
includes a controller 28a that performs header processing of incoming packets from the 
FBUS 18. The controller 28a extracts the packet headers and performs a 
microprogrammable source/destination/protocol hashed lookup (used for address 
30 smoothing) in SRAM. 
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The core processor 20 accesses the shared resources. The core processor 
20 has a direct communication to the SDRAM controller 26a to the bus interface 24 and 
to SRAM controller 26b via bus 32. However, to access the microengines 22a-22f and 
transfer registers located at any of the microengines 22a-22f, the core processor 20 access 
5 the microengines 22a-22f via the ASB Translator 30 over bus 34. The ASB translator 30 
can physically reside in the FBUS interface 28, but logically is distinct. The ASB 
Translator 30 performs an address translation between FBUS microengine transfer 
register locations and core processor addresses (i.e., ASB bus) so that the core processor 
20 can access registers belonging to the microengines 22a-22c. 

10 Although microengines 22 can use the register set to exchange data as 

described below, a scratchpad memory 27 is also provided to permit microengines to 
write data out to the memory for other microengines to read. The scratchpad 27 is 
coupled to bus 34. 

The processor core 20 includes a RISC core 50 implemented in a five 

15 stage pipeline performing a single cycle shift of one operand or two operands in a single 
cycle, provides multiplication support and 32 bit barrel shift support. This RISC core 50 
is a standard Strong Arm® architecture but it is implemented with a five stage pipeline 
for performance reasons. The processor core 20 also includes a 1 6 kilobyte instruction 
cache 52, an 8 kilobyte data cache 54 and a prefetch stream buffer 56. The core processor 
20 20 performs arithmetic operations in parallel with memory writes and instruction fetches. 
The core processor 20 interfaces with other functional units via the ARM defined ASB 
bus. The ASB bus is a 32-bit bi-directional bus 32. 
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Referring to FIG. 3, an exemplary microengine 22f includes a control store 
70 that includes a RAM which stores a microprogram. The microprogram is loadable by 
the core processor 20. The microengine 22f also includes controller logic 72. The 
controller logic includes an instruction decoder 73 and program counter (PC) units 72a- 
5 72d. The four micro program counters 72a-72d are maintained in hardware. The 

microengine 22f also includes context event switching logic 74. Context event logic 74 
receives messages (e.g., SEQJHEVENT_RESPONSE; FBI_EVENT_RESPONSE; 
SRAM EVENT RESPONSE; SDRAM JEVENT_RESPONSE; and ASB 
EVENT RESPONSE) from each one of the shared resources, e.g., SRAM 26a, SDRAM 

10 26b, or processor core 20, control and status registers, and so forth. These messages 

provide information on whether a requested function has completed. Based on whether or 
not a function requested by a thread has completed and signaled completion, the thread 
needs to wait for that completion signal, and if the thread is enabled to operate, then the 
thread is placed on an available thread list (not shown). The microengine 22f can have a 

15 maximum of e.g., 4 threads available. 

In addition to event signals that are local to an executing thread, the 
microengines 22 employ signaling states that are global. With signaling states, an 
executing thread can broadcast a signal state to all microengines 22. Receive Request or 
Available signal, any and all threads in the microengines can branch on these signaling 

20 states. These signaling states can be used to determine availability of a resource or 
whether a resource is due for servicing. 
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The context event logic 74 has arbitration for the four (4) threads. In one 
embodiment, the arbitration is a round robin mechanism. Other techniques could be used 
including priority queuing or weighted fair queuing. The microengine 22f also includes 
an execution box (EBOX) data path 76 that includes an arithmetic logic unit 76a and 
5 general purpose register set 76b. The arithmetic logic unit 76a performs arithmetic and 
logical functions as well as shift functions. The arithmetic logic unit includes condition 
code bits that are used by instructions described below. The registers set 76b has a 
relatively large number of general purpose registers that are windowed as will be 
described so that they are relatively and absolutely addressable. The microengine 22f 

10 also includes a write transfer register stack 78 and a read transfer stack 80. These registers 
are also windowed so that they are relatively and absolutely addressable. Write transfer 
register stack 78 is where write data to a resource is located. Similarly, read register stack 
80 is for return data from a shared resource. Subsequent to or concurrent with data 
arrival, an event signal from the respective shared resource e.g., the SRAM controller 

15 26a, SDRAM controller 26b or core processor 20 will be provided to context event arbiter 
74 which will then alert the thread that the data is available or has been sent. Both 
transfer register banks 78 and 80 are connected to the execution box (EBOX) 76 through 
a data path. 

Referring to FIG. 4, the microengine datapath maintains a 5-stage micro- 
20 pipeline 82. This pipeline includes lookup of microinstruction words 82a, formation of 
the register file addresses 82b, read of operands from register file 82c, ALU, shift or 
compare operations 82d, and write-back of results to registers 82e. By providing a write- 
back data bypass into the ALU/shifter units, and by assuming the registers are 
implemented as a register file (rather than a RAM), the microengine can perform a 
25 simultaneous register file read and write, which completely hides the write operation. 

The instruction set supported in the microengines 22a-22f support 
conditional branches. The worst case conditional branch latency (not including jumps) 
occurs when the branch decision is a result of condition codes being set by the previous 
microcontrol instruction. The latency is shown below in Table 1 : 

30 
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TABLE 1 



10 



| 1| 2| 3| 4| 5| 6| 1\ 8| 

microstore lookup | nl | cb j n2 | XX | bl | b2 | b3 | b4 | 
regaddrgen | | nl | cb | XX | XX | bl | b2 1 b3 | 
regfilelookup | | | nl | cb | XX | XX | bl | b2 | 
ALU/shifter/cc | | | | nl | cb | XX | XX | bl | 
writeback | | | m2| | nl | cb | XX | XX | 

where nx is pre-branch microword (nl sets cc's), cb is conditional 
branch, bx is post-branch microword and XX is an aborted microword 



As shown in Table 1, it is not until cycle 4 that the condition codes of nl 
15 are set, and the branch decision can be made (which in this case causes the branch path to 
be looked up in cycle 5). The microengine 22f incurs a 2-cycle branch latency penalty 
because it must abort operations n2 and n3 (the 2 microwords directly after the branch) in 
the pipe, before the branch path begins to fill the pipe with operation bl. If the branch is 
not taken, no microwords are aborted and execution continues normally. The 
20 microengines have several mechanisms to reduce or eliminate the effective branch 
latency. 

The microengines support selectable deferred branches. Selectable 
deferring branches are when a microengine allows 1 or 2 micro instructions after the 
branch to execute before the branch takes effect (i.e. the effect of the branch is "deferred" 
25 in time). Thus, if useful work can be found to fill the wasted cycles after the branch 
microword, then the branch latency can be hidden. A 1 -cycle deferred branch is shown 
below in Table 2 where n2 is allowed to execute after cb, but before bl: 
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TABLE 2 



| 1| 2| 3| 4| 5| 6| 7| 8| 

5 microstore lookup | nl | cb | n2 | XX | bl | b2 | b3 | b4 | 

reg addr gen | | nl | cb | n2 | XX | bl | b2 1 b3 | 
reg file lookup | | | nl | cb | n2 | XX | bl | b2 | 
ALU/shifter/cc | | | | nl | cb | n2 | XX | bl | 
writeback | | | | | nl | cb | n2 | XX | 

10 

A 2-cycle deferred branch is shown in TABLE 3 where n2 and n3 are both 
allowed to complete before the branch to bl occurs. Note that a 2-cycle branch deferment 
is only allowed when the condition codes are set on the microword preceding the branch. 

15 TABLE 3 



I 1 I 2| 3| 4| 5| 6| 1\ 8| 9| 
+ — + — + — + — + — + — + — + — + — + 

microstore lookup | nl | cb | n2 | n3 | bl | b2 | b3 | b4 | b5 | 
20 reg addr gen | | nl | cb | n2 | n3 | bl | b2 | b3 | b4 | 

reg file Ikup | | | nl | cb | n2 | n3 | bl | b2 | b3 | 
ALU/shftr/cc | | | | nl | cb | n2 | n3 | bl | b2 1 
writeback | | | | | nl | cb | n2 | n3 | bl | 



25 The microengines also support condition code evaluation. If the condition 

codes upon which a branch decision are made are set 2 or more microwords before the 
branch, then 1 cycle of branch latency can be eliminated because the branch decision can 
be made 1 cycle earlier as in Table 4. 
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TABLE 4 



| 1| 2| 3| 4| 5| 6| 7| 8| 

5 microstore lookup | nl | n2 | cb | XX | bl | b2 | b3 | b4 | 

regaddrgen | | nl | n2 1 cb | XX | bl | b2 1 b3 | 
reg file lookup | | | nl |n2 1 cb | XX | bl |b2 | 
ALU/shifter/cc | | | | nl | n2 1 cb | XX | bl | 
writeback | | | | | nl | n2 1 cb | XX | 

10 

In this example, nl sets the condition codes and n2 does not set the 
conditions codes. Therefore, the branch decision can be made at cycle 4 (rather than 5), 
to eliminate 1 cycle of branch latency. In the example in Table 5 the 1 -cycle branch 
deferment and early setting of condition codes are combined to completely hide the 
15 branch latency. That is, the condition codes (cc's) are set 2 cycles before a 1 -cycle 
deferred branch. 



TABLE 5 

20 | 1 | 2 | 3 | 4| 5| 6| 7| 8| 

microstore lookup | nl | n2 | cb | n3 | bl | b2 | b3 | b4 | 
regaddrgen | | nl | n2 | cb | n3 |bl | b2 1 b3 | 
reg file lookup | | | nl | n2 1 cb | n3 | bl | b2 | 
25 ALU/shifter/cc | | | | nl | n2 1 cb | n3 | bl | 

write back | | | | | nl | n2 | cb | n3 | 



In the case where the condition codes cannot be set early (i.e. they are set 
in the microword preceding the branch), the microengine supports branch guessing which 
30 attempts to reduce the 1 cycle of exposed branch latency that remains. By "guessing" the 
branch path or the sequential path, the microsequencer pre-fetches the guessed path 1 
cycle before it definitely knows what path to execute. If it guessed correctly, 1 cycle of 
branch latency is eliminated as shown in Table 6. 
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TABLE 6 
guess branch taken /branch is taken 

5 

| 1| 2| 3| 4| 5| 6| 7| 8| 

microstore lookup | nl | cb | nl | bl | b2 | b3 | b4 | b5 | 
regaddrgen | | nl | cb | XX | bl | b2 | b3 | b4 1 
10 reg file lookup | | | nl | cb | XX j bl | b2 | b3 | 

ALU/shifter/cc | | | | nl | cb | XX | bl | b2 | 
write back | | | | | nl | cb | XX | bl | 

If the microcode guessed a branch taken incorrectly, the microengine still only wastes 1 
15 cycle as in TABLE 7 

TABLE 7 

guess branch taken /branch is NOT taken 

20 

I 1 1 2| 3| 4| 5| 6| 7| 8| 

microstore lookup | nl | cb | nl | XX | n2 | n3 | n4 1 n5 | 
regaddrgen | |nl |cb|nl |XX|n2|n3 |n4| 
25 reg file lookup | | | nl | cb | nl | XX | n2 | n3 | 

ALU/shifter/cc | | | | nl | cb | nl | XX | n2 | 
writeback I I I I | nl | cb | nl | XX | 

However, the latency penalty is distributed differently when microcode 
30 guesses a branch is not taken. For guess branch NOT taken and the branch is NOT taken 
there are no wasted cycles as in Table 8. 
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Table 8 
I 1| 2| 3| 4| 5| 6| 7| 8| 

. + + H + + + + 1 + 

microstore lookup | nl | cb | nl | n2 | n3 | n4 | n5 | n6 | 
reg addr gen | | nl | cb | nl | n2 | n3 | n4 | n5 | 
reg file lookup | | | nl | cb | nl | n2 | nl | b4 | 
ALU/shifter/cc | | | | nl | cb | nl | n2 | n3 | 
writeback | | | | | nl | cb | nl | n2 | 

However for guess branch NOT taken /branch is taken there are 2 wasted 
cycles as in Table 9. 

Table 9 



15 



I 1 | 2| 3| 4| 5 | 6| 7| 8| 

microstore lookup | nl | cb | nl | XX | bl | b2 | b3 | b4 1 
reg addr gen | | nl | cb | XX | XX | bl | b2 | b3 | 
20 reg file lookup | | | nl | cb | XX | XX | bl | b2 | 

ALU/shifter/cc | | | | nl | cb | XX | XX | bl | 
write back | | | | | nl | cb | XX | XX | 

The microengine can combine branch guessing with 1 -cycle branch deferment to improve 
25 the result further. For guess branch taken with 1 -cycle deferred branch/branch is taken is 
in Table 10. 
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Table 10 



| 1| 2| 3| 4| 5| 6| 7| 8| 

: + — + — + — + — + — + — + — + — + 

5 microstore lookup | nl | cb | n2 1 bl | b2 | b3 | b4 1 b5 | 

reg addr gen | | nl | cb | n2 1 bl | b2 1 b3 | b4 1 
reg file lookup | | | nl |cb|n2|bl |b2|b3 | 
ALU/shifter/cc | | | |nl |cb|n2|bl |b2| 
writeback I I I I | nl | cb | n2 | bl | 

10 

In the case above, the 2 cycles of branch latency are hidden by the execution of n2, and 
by correctly guessing the branch direction. 

If microcode guesses incorrectly, 1 cycle of branch latency remains 
exposed as in Table 1 1 (guess branch taken with 1 -cycle deferred branch/branch is NOT 
15 taken). 



Table 11 

| 1 | 2 | 3 | 4 | 5| 6| 7| 8| 9| 

microstore lookup | nl | cb | n2 | XX | n3 | n4 | n5 | n6 | n7 j 
reg addr gen | | nl | cb | n2 | XX | n3 | n4 1 n5 | n6 | 
reg file lkup | | | nl | cb | n2 | XX | n3 | n4 |n5 | 
ALU/shftr/cc | | | | nl | cb | n2 | XX | n3 | n4 1 
25 write back | | | I | nl | cb | n2 | XX | n3 | 



If microcode correctly guesses a branch NOT taken, then the pipeline 
flows sequentially in the normal unperturbed case. If microcode incorrectly guesses 
30 branch NOT taken, the microengine again exposes 1 cycle of unproductive execution as 
shown in Table 12. 
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Table 12 



guess branch NOT taken/branch is taken 

5 I 1 1 2| 3| 4| 5| 6| 7| 8| 9| 

microstore lookup | nl | cb | n2 | XX | bl | b2 | b3 | b4 1 b5 | 
regaddrgen | |nl | cb | n2 1 XX | bl | b2 | b3 | b4 1 
regfilelkup | | | nl | cb | n2 | XX | bl | b2 | b3 | 
10 ALU/shftr/cc | | | | nl | cb | n2 | XX | bl | b2 | 

writeback | | | | | nl | cb | n2 | XX | bl | 



where nx is pre-branch microword (nl sets cc's) 
cb is conditional branch 
15 bx is post-branch microword 

XX is aborted microword 



In the case of a jump instruction, 3 extra cycles of latency are incurred because the 
branch address is not known until the end of the cycle in which the jump is in the ALU 
20 stage (Table 13). 

Table 13 

| 1| 2| 3| 4| 5| 6| 7| 8| 9| 
25 + 1- — + — + — + — + — + — + — + — + 

microstore lookup | nl | jp | XX | XX | XX | jl | j2 | j3 | j4 1 

regaddrgen | | nl | jp | XX | XX | XX | jl | j2 | j3 | 

regfilelkup | | | nl | jp | XX | XX | XX | jl | j2 | 

ALU/shftr/cc | | | | nl | jp | XX | XX | XX | jl | 
30 writeback | | | | | nl | jp | XX | XX | XX | 
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Referring to FIG. 5, the microengines support various branch instructions 
such as those that branch on condition codes. In addition, the microengines also support 
branch instructions that branch on a processor state. 

A format as shown in FIG. 5 uses br_mask field is used to specify branch. 
5 For branch mask = 15, the extended field is used to specify the various signal and state 
signals as listed below. 

BR_INP_STATE 

The BR_INP_STATE instruction branches if a state of a specified state 
10 name is set to 1. A state is set to 1 or 0 by a microengine in the processor 10 and 
indicates the current processing state. The state of the state name is available to all 
microengines. The instruction can have the following format 

br_inp_state[state_name, label#], optional Joken 
The field label# is a symbolic label corresponding to the address of an 
1 5 instruction to branch to. The field "State_name" is the state name. For example, if the 
state name is ree_req_avail this state indicates when set that the RCVREQ FIFO has 
room available for another receive request. Other states could be used. This instruction 
is used to integorrate a state the microengine and to perform a branch operation based 
on the state. 

20 The instruction can also include an optional_token defer 1 that causes the 

processor to execute the instruction following this instruction before performing the 
branch operation. Other architectures could support additional defer optional tokens, e.g., 
defer 2, defer 3 and so forth. In addition the branch operation could be to branch on state 
name not being set, i.e., cleared. 

25 

BRJSIGNAL 

A second branch instruction BR_! SIGNAL branches if the specified signal 
is deasserted. If the signal is asserted, the instruction clears the signal and does not 
branch. The SRAM and SDRAM signals are presented to the microengine two cycles 
30 after the last Long word is written to the transfer register. The second from last Long 

word is written 1 cycle after the signal. All other Long words are valid when the signal is 
submitted. When using this instruction, the programmer should appropriately time 
reading of transfer registers to ensure that proper data is read 
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Example: .xfer_prder SxferO Sxferl Sxfer2 $xfer3 
sramfread, SxferO, opl, 0, 2], sig_done 
wait#: 

br_!signal[sram, wait#], guess_branch 
nop;delay 1 cycle before reading SxferO 
alu[gpr0,0,b,$xferO];valid data is written to gprO 
alu[gprl,0,b,Sxferl];valid data is written to gprO 
self#: 
br[self#]. 



The extended branch field is used for branches on various 
context_swapping signals. EXT_BRANCH_TYPE: extended field to BRANCH_TYPE 
field." EXT_BRANCHJTYPE/=<20: 1 7>,.default=<EXT_BRANCH_TYPE/SRAM>, 
.validity=<.GTR[.TEMEl, 0]> 

1 5 The signals can include the following: SRAM = 0, SDRAM = 1 , FBI = 2, 

INTER JTHREAD = 3, AUTO_PUSH = 4, START JtECEIVE = 5, SEQ_NUM1 = 6, 
SEQ_NUM2 = 7, PCI = 8, GET_Q_AVAIL = B, PUT_Q_AVAIL - C, 
REC_REQ_AVAIL = D, PUSH_PROTECT = E and PAR_ERR = F 

Each microengine 22a_22f supports multithreaded execution of four 

20 contexts. One reason for this is to allow one thread to start executing just after another 
thread issues a memory reference and must wait until that reference completes before 
doing more work. This behavior maintains efficient hardware execution of the 
microengines because memory latency is significant. Stated differently, if only a single 
thread execution was supported, the microengines would sit idle for a significant number 

25 of cycles waiting for references to return and thereby reduce overall computational 

throughput. Multithreaded execution allows an microengines to hide memory latency by 
performing useful independent work across several threads. Two synchronization 
mechanisms are supplied in order to allow a thread to issue an SRAM or SDRAM 
reference, and then subsequently synchronize to the point in time when that reference 

30 completes. 

One mechanism is Immediate Synchronization. In immediate 
synchronization, the microengine issues the reference and immediately swap out that 
context. The context will be signaled when the corresponding reference completes. Once 
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signaled, the context will be swapped back in for execution when a context_swap event 
occurs and it is its turn to run. Thus, from the point of view of a single context's 
instruction stream, the microword after issuing the mem reference does not get executed 
until the reference completes. 
5 A second mechanism is Delayed Synchronization. In delayed 

synchronization, the microengine issues the reference, and then continues to execute 
some other useful work independent of the reference. Some time later it could become 
necessary to synchronize the thread's execution stream to the completion of the issued 
reference before further work is performed. At this point a synchronizing microword is 
10 executed that will either swap out the current thread, and swap it back in sometime later 
when the reference has completed, or continue executing the current thread because the 
reference has already completed. Delayed synchronization is implemented using two 
different signaling schemes: 

If the memory reference is associated with a transfer register, the signal 
15 from which the thread is triggered is generated when the corresponding transfer register 
valid bit is set or cleared. For example, an SRAM read which deposits data into transfer 
register A would be signaled when the valid bit for A is set. If the memory reference is 
associated with the transfer FIFO or the receive FIFO, instead of a transfer register, then 
the signal is generated when the reference completes in the SDRAM controller 26a. Only 
20 one signal state per context is held in the microengines scheduler, thus only one 
outstanding signal can exist in this scheme. 

There are at least two general operational paradigms from which 
microcontroller microprograms could be designed. One would be that overall 
microcontroller compute throughput and overall memory bandwidth are optimized at the 
25 expense of single thread execution latency. This paradigm would make sense when the 
system has multiple microengines executing multiple threads per microengine on 
unrelated data packets. 

A second one is that microengine execution latency should be optimized at 
the expense of overall microengine compute throughput and overall memory bandwidth. 
30 This paradigm could involve execution of a thread with a realjime constraint, that is, a 
constraint which dictates that some work must absolutely be done by some specified time. 
Such a constraint requires that optimization of the single thread execution be given 
priority over other considerations such as memory bandwidth or overall computational 
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throughput. A real_time thread would imply a single microengine that executes only one 
thread. Multiple threads would not be handled because the goal is to allow the single 

real_time thread to execute as soon as possible execution of multiple threads would 

hinder this ability. 

5 Referring to FIG. 6, the two register address spaces that exist are Locally 

accessibly registers, and Globally accessible registers accessible by all microengines. 
The General Purpose Registers (GPRs) are implemented as two separate banks (A bank 
and B bank) whose addresses are interleaved on a word-by-word basis such that A bank 
registers have lsb=0, and B bank registers have lsb=l . Each bank is capable of 
10 performing a simultaneous read and write to two different words within its bank. 

Across banks A and B, the register set 76b is also organized into four 
windows 76b 0 -76b 3 of 32 registers that are relatively addressable per thread. Thus, 
thread_0 will find its register 0 at 77a (register 0), the thread_l will find its registerj) at 
77b (register 32), thread_2 will find its registerj) at 77c (register 64), and thread J3 at 77d 

15 (register 96). Relative addressing is supported so that multiple threads can use the exact 
same control store and locations but access different windows of register and perform 
different functions. The use of register window addressing and bank addressing provide 
the requisite read bandwidth while using only dual ported RAMS in the microengine 22f. 

These windowed registers do not have to save data from context switch to 

20 context switch so that the normal push and pop of a context swap file or stack is 

eliminated. Context switching here has a 0 cycle overhead for changing from one context 
to another. Relative register addressing divides the register banks into windows across 
the address width of the general purpose register set. Relative addressing allows access 
any of the windows relative to the starting point of the window. Absolute addressing is 

25 also supported in this architecture where any one of the absolute registers may be 
accessed by any of the threads by providing the exact address of the register. 

Addressing of general purpose registers 78 can occur in 2 modes 
depending on the microword format. The two modes are absolute and relative. In 
absolute mode, addressing of a register address is directly specified in 7-bit source field 

30 (a6-a0 or b6-b0), as shown in Table 14: 
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Table 14 

7 6 5 4 3 2 1 0 
+ — + — + — + — + — + — + — + — + 

5 AGPR: |a6|0|a5|a4|a3|a2|al|a0| a6=0 

BGPR: |b6|l |b5|b4|b3|b2|bl|b0| b6=0 

SRAM/ASB:| a6| aS| a4j 0 | a3| a2| al | a0| a6=l, a5=0, a4=0 SDRAM: 
| a6| a5| a4| 0 1 a3| a2| alf a0| a6=l, a5=0, a4=l 

1 0 register address directly specified in 8-bit dest field (d7-d0) Table 1 5 : 

Table 15 

7 6 5 4 3 2 1 0 
15 +—+„.+.„+ — +.--+-_+ — + — + 

A GPR: | d7| d6| d5| d4| d3| d2| dl| dO| d7=0, d6=0 
B GPR: | d7| d6| d5| d4| d3| d2| dl | dO| d7=0, d6=l 
SRAM/ASB:| d7| d6| d5| d4| d3| d2| dl| dO| d7=l, d6=0, d5=0 
SDRAM: | d7| d6| d5| d4| d3| d2| dl| dO| d7-l, d6=0, d5=l 

If <a6:a5>=l,l, <b6:b5>=l,l, or <d7:d6>=l,l then the lower bits are 
interpreted as a context-relative address field (described below). When a non-relative A 
or B source address is specified in the A, B absolute field, only the lower half of the 
SRAM/ASB and SDRAM address spaces can be addressed. Effectively, reading 
absolute SRAM/SDRAM devices has the effective address space; however, since this 
restriction does not apply to the dest field, writing the SRAM/SDRAM still uses the full 
address space. 

In relative mode, addresses a specified address is offset within context 
space as defined by a 5-bit source field (a4-a0 or b4-bO)Table 1 6: 
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Table 16 

7 6 5 4 3 2 1 0 
+-„+--.+„.+__.+__+_„+_„+_„+ 

5 AGPR: |a4|0|context|a3|a2|al|a0|a4=0 

B GPR: | b4| 1 |context| b3| b2| bl | b0| b4=0 
SRAM/ASB:|ab4| 0 |ab3|context| b2| bl|abO| ab4=l, ab3=0 
SDRAM: |ab4| 0 |ab3|context| b2| b 1 |abO| ab4=l , ab3=l 



10 or as defined by the 6-bit dest field (d5-d0) Table 1 7: 

Table 17 

7 6 5 4 3 2 1 0 
1 5 +— + — +---+—+—+—+._+—+ 

AGPR: |d5|d4|context|d3|d2|dl|d0| d5=0, d4=0 
B GPR: |d5|d4|context|d3|d2|dl|d0| d5=0, d4=l 
SRAM/ASB:| d5| d4| d3|context| d2| dl| d0| d5=l, d4=0, d3=0 
SDRAM: | d5| d4| d3|context| d2| dl| d0| d5=l, d4=0, d3=l 

20 

If <d5:d4>=l,l, then the destination address does not address a valid 
register, thus, no dest operand is written back. 



Other embodiments are within the scope of the appended claims. 
25 What is claimed is: 
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1 . A computer instruction comprises: 

a branch instruction that causes an executing instruction stream to branch 
to an instruction at an address specified in the instruction if a state of a specified state 
name is a specified value. 

5 

2. The instruction of claim 1 wherein the state is set to a logic one or a logic 
zero by a processor and indicates the currently processing state. 

3. The instruction of claim 1 wherein the state is set to logic one or a logic 
10 zero by a microengine in a parallel processor and indicates the currently processing state. 

4. The instruction of claim 2 wherein the state is available to all 
microengines. 

15 5. The instruction of claim 1 further comprising: 

an optional token that is set by a programmer and specifies a number i of 
instructions to execute following the branch instruction before performing the branch 
operation where the number of instructions can be specified as one, two or three. 

20 6. The instruction of claim 1 wherein the instruction has the following 

format: 

br_inp_state[state_name, label#], optionaMoken. 

7. The instruction of claim 1 wherein the instruction causes a branch if the 
25 value of the specified state name is set to a logic one. 

8. The instruction of claim 1 wherein the instruction causes a branch if the 
value of the specified state name is cleared to a logic zero. 

30 9. The instruction of claim 1 wherein the state name is the name assigned to 

an executing context. 
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10. A method of operating a processor comprises: 
evaluating a value of a specified state name; and 

performing a branching operation based on the value of the specified state 
name being set or cleared. 

5 

11. The method of claim 10 wherein the state is set to a logic one or a logic 
zero by a processor and indicates the currently processing state. 

12. The method of claim 1 1 wherein the state is set to logic one or a logic zero 
10 by a microengine in a parallel processor and indicates the currently processing state. 

13. The method of claim 1 1 further comprising; 

branching to an instruction at a branch target field specified as a label in 

the instruction. 
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14. The method of claim 1 1 further comprising: 

executing a number i of instructions following execution of the branch 
instruction before performing the branch operation based on evaluating an optional token 
that is set by a programmer. 

15. The method of claim 1 1 further comprising: 

evaluating an optional token that is set by a programmer; and 
executing one instruction following execution of the branch instruction 
before performing the branch operation based on whether the optional token is set. 



16. A processor comprises: 

a register stack; 

an arithmetic logic unit coupled to the register stack and a program control 
store that stores a branch instruction that causes the processor to: 
30 evaluate a value of a specified state name; and 

perform a branching operation based on the value of the specified state 
name being set or cleared. 
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1 7. The processor of claim 16 wherein the processor is a parallel processor 

with the register stack an arithmetic logic unit is part of a microengine, and the processor 
further comprises: 

at least an additional microengine, the microengine comprising: 
5 a register stack; 

an arithmetic logic unit coupled to the register stack and a program control 
store, and wherein the state is set to logic one or a logic zero by one of the microengines 
and indicates the currently processing state. 

10 18. The processor of claim 1 6 further comprising: 

a branch target field specified as a label in the instruction. 

1 9. A computer program product residing on a computer readable medium for 
causing a processor to perform a function comprises instructions causing the processor to: 

1 5 evaluate a value of a specified state name; and 

perform a branching operation based on the value of the specified state 
name being set or cleared. 

20. The computer program product of claim 19 wherein instructions to 

20 perform a branching operation branch if the value of the specified state name is set to a 
logic one. 
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branch instruction: 

♦ "♦fU?*?!JIJf + ?? It+ll U 21 20 19 18 17 1« 15 14 13 12 U 10 9 8 7 6 5 4 3 2 1 0 
BRANCH ]_l^]_li_bf_«^jc^k^ Idetbrlgm"b«nch"cidl 

defbr: A value of 0, 1 or 2 may be specified. If non-zero, the value indicates that the following I or 2 microwords will be 
allowed to execute before the branch operation takes place. 

h£JIS' SFVS * C b [™$ pat 5 Wi L ! ** lak ! a t 5 u iP refclch branch microword address. Otherwise prefetch the non- 
branch path. This field is only allowed to be set when dcfbr=0 or defbr* 1 . i»«**wi 

branch address: branch address conditionally or unconditionally selected. 

br_mask: Is decoded to the following options: 

1) unconditional branch 

2) branch when ALU<31>« I (<0) 

3) branch when ALU<31>=0 (>=0) 

4) branch when ALU<3 1 >= 1 OR ALU<3 1 :0>«0 (<=0) 

5) branch when ALU<31>=0 AND AJLIK3 1 :0>M) (X)) 

6) branch when ALU<3 1 :0>-0 (=0) 

7) branch when ALU<3 1 :0>= I (!«0) 

8) branch when specified context mask «- current context 

9) branch when specified context mask !*= current context 

1 0) branch on cany-out set 

11) branch on carry-out clear 

1 5) look at extended branch field to further decode branch type 
extended.br: branches on various context-swapping signals or other signals, 
evpip: indicates pipe stage that this branch should be evaluated in 
c msk: specifies a context number with which to conditionally branch on. 

branch cmd further specifies the type of branch, e.g., looks at condition codes or some other branch criteria. 



FIG. 5 



WO 01/16715 



6/6 



PCT/US00/23983 



B BANK 



A BANK 



} 



THREAD 3 



} 
} 



THREAD 0 



THREAD 3 



J^THREADJ) 



F/C. G 



INTERNATIONAL SEARCH REPORT 



International application No. 
PCT/USOO/23983 



A. CLASSIFICATION OF SUBJECT MATTER 

IPC(7) :G06F 9/32. 9/26 
USCL : 712/233,234 
According to International Patent Classification (IPC) or to both national classification and IPC 

B. FIELDS SEARCHED ~~ " 



Minimum documentation searched (classification system followed by classification symbols) 
U.S. : 712/233,234 



Documentation searched other than minimum documentation to the extent that such documenu are included in the fields searched 



Electronic data base consulted during the international search (name of data base and. where practicable, search terms used) 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category* 



Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



X 
Y 

Y 
Y 



US 5,517,628 A (MORRISON et al) 14 May 1996, col. 50, lines 
10-24; col." 49, lines 35-46; 

Abstract; col. 1, lines 19-25; col. 33, lines 59-67; col. 44, line 61 - 
col. 45, line 12; col. 49, lines 35-46; col. 50, lines 10-67; col. 52, 
lines 4-8; Figs. 6-7 and 19. 

US 5,659,722 A (BLANER et al) 19 August 1997, Abstract; Tables 
1 and 2; Fig. 6 

US 5,428,809 A [Coffin et al] 27 June 1995, Abstract; col. 3, lines 
20-32 



1-2, 7-11, 16 and 
19-20 

1-20 



1-20 



3-4, 12. and 16- 
17 



I Further documents are listed in the continuation of Box C. [ ] 



See patent family annex. 



Special categories of cited document!" 

document defining the general state of the art which is not considered 
to be of particular relevance 

earlier document published on or after the international filing date 

document which may throw doubts on priority claim<s) or which is 
cited to establish the publication date of another citation or other 
special reason (as specified) 

document referring to an oral disclosure, use, exhibition or other 
means 

document published prior to the international filing date but bter than 
the priority date claimed 



■O" 
.p. 

Date of the actual completion of the international search 



later document published after the international filing date or priority 
date and not in conflict with the application but cited to understand 
the principle or theory underlying the invention 

document of particular relevance; the claimed invention cannot be 
considered novel or cannot be considered to involve an inventive ttep 
when the document is taken alone 

document of particular relevance; the claimed invention cannot be 
considered to involve an inventive ttep when the document is 
combined with one or more other such documents, auoh combination 
being obvious to a person skilled in the art 

document member of the tame patent famih/ 



05 OCTOBER 2000 



Date of mailing of 



port 



Name and mailing address of the ISA/US 
Commissioner of Patents and Trademarks 
Box PCT 

Washington, D.C 20231 
Facsimile No. (703) 306-5404 



Authorized officer 

WEN-TAI LIN V ^ft\ 
Telephone No. (703) 305-4875 



Form PCT/1SA/2I0 (second sheet) (July 1998)w 



